Proximity-based authentication

ABSTRACT

A first device requests a protected resource (managed by a second device). A first authentication is performed by the second device upon receipt of the request. The second device provides an audio message back to the first device, which plays the audio message over a speaker. A third device captures the audio message as audio and uses the audio message to request a second authentication from the second device. The second device provides an authenticated session handle back to the first device for accessing the protected resource when both the first and second authentications are successful.

This application is a continuation of U.S. patent application Ser. No.14/168,223, filed Jan. 30, 2014, which is incorporated herein byreference in its entirety.

BACKGROUND

As the Internet grows ever larger, the need for stronger authenticationbecomes more important. Name and password authentication mechanisms arenot providing the total needed level of user validation. As a result,and in many instances, multifactor authentication is being used in theindustry to fill this need for stronger authentication. However, theproblem with most multifactor authentication mechanisms is that theyrequire more interaction (input or attention) from the end user.Moreover, each time data entry is required from the user, errors areintroduced and the solution becomes appealing to the end user.

Multifactor authentication is typically provided with at least two ofthree authentication factors. The three factors are: 1) “what you know,”2) “what you are,” and 3 “what you have.” Name and password credentialsare a case of “what you know” (1). Furthermore, there are many hardwaredevices that are used to fill the need of, “what you have” (3). Theproblem with hardware devices providing “what you have” (3) is that thehardware devices require the end user to carry another device, such ashardware tokens. The problem that can be solved by an end user usinghis/her mobile device (iPad®, iPhone®, Android, etc.) as a hardwaretoken, but this actually causes yet another problem. Specifically, theend user must have special hardware and/or software on his/her desktopto interface with his/her mobile device (hardware), or he/she mustprovide information read from the desktop screen into the mobile device.This means that the end user must first type in his/her name andpassword into the desktop; then read a “challenge” presented on thescreen; type an answer to the “challenge” into the mobile device; readthe response on the mobile device; and then type the response into thedesktop interface as an appropriate response. In some situations,processing steps can be removed but not all of the steps can be removedwith the current-state of technology. Essentially, the end user is thego-between of the mobile device and the login prompt of the desktopinterface.

Moreover, at no point in time is there any assurance that the mobiledevice of the end user is in close proximity to the desktop with theabove-discussed scenario. The response to the “challenge question” sentfrom the desktop interface to the mobile device can be remotely providedto someone at the desktop, who may not even be the end user.

SUMMARY

Various embodiments of the invention provide techniques forproximity-based authentication. In an embodiment, a method forproximity-based authentication is presented.

Specifically, an audio message is sent to a device. Next, a responsemessage is received in response to the audio message that was sent tothe device. Finally, a determination is made to whether or not toprovide the device access to a resource based on evaluation of the audiomessage and the response message.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A-1E are flow diagrams depicting architectures and processing forproximity-based authentication, according to an example embodimentpresented herein.

FIG. 2 is a diagram of a method proximity-based authentication,according to an example embodiment.

FIG. 3 is a diagram of another method for proximity-basedauthentication, according to an example embodiment.

FIG. 4 is a diagram of a proximity-based authentication system,according to an embodiment.

DETAILED DESCRIPTION

A “resource” includes a user, service, system, device, directory, datastore, groups of users, combinations and/or collections of these things,etc. A “principal” is a specific type of resource, such as an automatedservice or user that at one time or another is an actor on anotherprincipal or another type of resource. A designation as to what is aresource and what is a principal can change depending upon the contextof any given network transaction. Thus, if one resource attempts toaccess another resource, the actor of the transaction may be viewed as aprincipal. Resources can acquire and be associated with uniqueidentities to identify unique resources during network transactions.

An “identity” is something that is formulated from one or moreidentifiers and secrets that provide a statement of roles and/orpermissions that the identity has in relation to resources. An“identifier” is information, which may be private and permits anidentity to be formed, and some portions of an identifier may be publicinformation, such as a user identifier, name, etc. Some examples ofidentifiers include social security number (SSN), user identifier andpassword pair, account number, retina scan, fingerprint, face scan, etc.

A “processing environment” defines a set of cooperating computingresources, such as machines (processor and memory-enabled devices),storage, software libraries, software systems, etc. that form a logicalcomputing infrastructure. A “logical computing infrastructure” meansthat computing resources can be geographically distributed across anetwork, such as the Internet. So, one computing resource at networksite X can be logically combined with another computing resource atnetwork site Y to form a logical processing environment.

The phrases “processing environment,” “cloud processing environment,”and the term “cloud” may be used interchangeably and synonymouslyherein.

Moreover, it is noted that a “cloud” refers to a logical and/or physicalprocessing environment as discussed above.

Various embodiments of this invention can be implemented in existingnetwork architectures.

Also, the techniques presented herein are implemented in (and residewithin) machines, such as processor(s) or processor-enabled devices(hardware processors). These machines are configured and programmed tospecifically perform the processing of the methods and system presentedherein. Moreover, the methods and system are implemented and residewithin a non-transitory computer-readable storage media ormachine-readable storage medium and are processed on the machines(processors) configured to perform the methods.

Of course, the embodiments of the invention can be implemented in avariety of architectural platforms, devices, operating and serversystems, and/or applications. Any particular architectural layout orimplementation presented herein is provided for purposes of illustrationand comprehension of particular embodiments only and is not intended tolimit other embodiments of the invention presented herein and below.

It is within this context that embodiments of the invention are nowdiscussed within the context of the FIGS. 1A-1E and 2-4.

FIGS. 1A-1E are flow diagrams depicting architectures and processing forproximity-based authentication, according to an example embodimentpresented herein. The FIGS. 1A-1B depict example architectures forperforming multifactor authentication among a mobile device (mobilephone in the FIG. 1B and a fixed landline phone in the FIG. 1B), adesktop device (such as a desktop computer), and a server (can be acloud);

These architectures FIG. 1A-1B are shown for purposes of illustration ofparticular embodiments of the invention; it is noted that otherembodiments of the invention (FIGS. 2-4) need not be limited to thesearchitectures FIGS. 1A-1B, as other hardware and software architecturescan be used as well.

The FIG. 1A depicts an architecture for mobile device audioauthentication. The architecture includes a mobile device (smart phoneor phone but is not so limited (because the mobile device can also be atablet, a wearable processing device, a laptop, etc.), a desktop device(computer), and an Audio Authentication Server (AAS).

The FIG. 1B depicts another architecture for phone-based authentication.The architecture includes a fixed phone (landline), a laptop, and anAAS.

The FIG. 1C depicts a processing flow for various aspects of theinvention utilizing the architecture 1A. The processing flow isdiscussed within the context of an end user attempting to authenticatevia a multifactor proximity-based authentication technique.

The end-user visits a protected resource (requiring multifactorauthentication) using an interface, such as a browser-based interface ofthe computer (can be a laptop or tablet as well). The request for theprotected resource is redirected to the AAS for initiating andperforming the multifactor authentication. The user is prompted forhis/her user name and password (“what the user knows” and first part ofthe multifactor authentication). The remaining portion of themultifactor authentication is performed automatically on behalf of theuser, without any user interaction being required.

The mobile device is initially configured to execute an application(mobile app) on the processor(s) of the mobile device and residing inand programmed within memory and/or non-transitory computer-readablestorage media of the mobile device. The mobile app can execute in theforeground or background of the mobile device.

Moreover, the mobile device is already registered with the AAS for useof the multifactor audio authentication approach (discussed below). Aspart of the registration process, the mobile device has a Public KeyInfrastructure (PKI) key pair (public and private) stored in memoryand/or storage of the mobile device. The public key of the key pair isshared with the AAS.

The AAS is initially configured to use a secure protocol forcommunication, such as Secure Socket Layer (SSL) and/or Transport LayerSecurity (TLS).

Now, reference is made to the FIG. 1C to discuss the mobile audiomultifactor authentication within the context of a user at a desktop andhaving a phone (mobile device).

At 1 (of the FIG. 1C), the end user (user) is interacting with thedesktop device (which, minimally, includes a speaker, a microphone, anda browser interface (browser)) and selects (via the browser) a UniformResource Locator (URL) link associated with a protected resource. Again,the protected resource is associated with a policy that necessitatesmultifactor authentication before access is permitted to the user. Forexample, an administrator may have configured the protected resource torequire multifactor authentication for access. In another case, adynamic service can determine when the user selects the protectedresource that multifactor authentication is required based on anidentity of the protected resource and/or an identity for the user.

In the present example, the two factors required for the multifactorauthentication are: 1) a name and password pair for the user; and 2) theinformation discussed below.

At 2, the browser uses a Hypertext Markup Language (HTML) form to getthe name and password from the user, which is then sent to the AAS as aPOST.

At 3, the AAS validates the name and password from the user (such as,via a Lightweight Directory Access Protocol (LDAP) mechanism, or othermechanisms). Then, the AAS generates a challenge string. In anembodiment, the string is randomly generated so that it cannot bepredicted. The challenge string and user identification (user IDacquired from the validated name and password of the user) are encodedinto an audio format. This audio encoding can be achieved via existingmechanisms available on modems and other devices.

At 4, the AAS returns an HTML page to the browser (of the desktopdevice); the HTML page includes an authentication application or ascript (such as a JAVA™ script, or other script), and the HTML page alsoincludes an audio file that the browser is to play to generate sound onthe speaker of the desktop device.

At 5, the application or script begins to play the audio file sent andthen listens for a reply by monitoring the microphone of the desktopdevice. The processing at 5 can be repeated multiple times until atimeout is detected by the desktop device. The number of iterationsbefore a timeout occurs can be preconfigured, provided as an operatingparameter, or be based on a predefined elapsed period of time.

At 6, the mobile application of the mobile device “hears” the soundgenerated from the speaker of the desktop device by monitoring themicrophone of the mobile device and decodes the challenge string anduser ID embedded in the audio stream detected over the microphone of themobile device. The challenge string and the user ID are then signed bythe private key of the mobile device (the public key of the mobiledevice previously registered with the AAS). In an embodiment, a policyevaluated by the mobile application may also require that the mobileapplication encrypt the signed challenge string and user ID. In anembodiment and for added security, another policy may necessitate thatthe mobile application prompt the user on the mobile device, via aninterface of the mobile application, for the user to supply someadditional code, such as a Personal Identification Number (PIN). Thesigned, and optionally encrypted, challenge string and user ID areencoded into an audio file.

At 7, the mobile application of the mobile device sends the audio filethat it produced in 6 by playing the audio file on a speaker of themobile device, which is received at the speaker of the desktop device(which the desktop device is monitoring for a reply in 5 above, via themicrophone of the desktop device).

At 8, the desktop device demodulates the signed, and optionallyencrypted, audio file being streamed as audio from the mobile device. Inan embodiment, the desktop device just captures and records the audiostream.

At 9, the desktop device sends the captured or demodulated audio streamas a POST to the AAS for validation.

Assuming, the AAS can successfully validate the captured or demodulatedaudio stream using the public key of the mobile device, the AAS returnsan authentication session handle back to the browser of the desktopdevice for the user to access the protected resource (process originatedat 1—as a response to the original POST message sent from the browser).

The above-noted embodiment utilized multifactor authentication in whicha desktop device and a mobile device each utilized their respectivespeakers and microphones to perform that audio authentication. The FIG.1D depicts an embodiment in which a microphone on the desktop device isnot used and in which a speaker on the mobile device is not used.

The processing for the embodiment of the FIG. 1D includes the processing1-4 depicted in the FIG. 1C. However, the remaining processing of theFIG. 1C (beginning at 5) is different.

Specifically, at 5 a, the desktop device makes a check to the AAS todetermine if authentication of the user name and password verificationcompleted. If so, at 5 b, the desktop device begins playing the audiofile (as described above) out of the speaker of the desktop device withthe user ID and challenge encoded in the audio stream (may also bereferred to as an “audio message”). The audio message is again repeateduntil completed (multifactor authentication confirmed with a sessionhandle returned to the browser from the AAS), halted manually by theuser (using the browser or an interface of the mobile application), or atimeout is detected (as discussed above at 5 with the discussion of theFIG. 1C).

At 6 b, the mobile application of the mobile device detects, via themobile device's microphone, the audio message and decodes it. Thechallenge string and user ID embedded in the decoded audio message aresigned using the private key of the mobile device. Again, andoptionally, the signed decoded challenge string and user ID may also beencrypted. Similarly, an interface of the mobile application may requirethe user manually enter a code, such as a PIN to proceed at this point.

At 7 b, the mobile application sends the signed, and optionallyencrypted, audio message to the AAS using a secure protocol, such as SSLor TLS.

At 8 b, the AAS validates the signed, and optionally encrypted, audiomessage using the public key of the mobile device and initially signedwith the private key of the mobile device.

Assuming, authentication is successful the AAS returns a valid sessionhandle (session identifier) to the browser of the desktop device for theuser to access the protected resource. In an embodiment, the sessionhandle is returned as a response to the original POST issued by thebrowser.

Reference is now made to the architecture presented in the FIG. 1B withreference to the processing of the FIG. 1E to describe other embodimentsof the invention.

The user attempts to access a protected resource on a desktop device(laptop, or any processor-enabled device). In the example scenariopresented in the FIG. 1E, the user uses a browser to access a link orsupply an address for a protected resource. This causes a redirection ofthe request for the protected resource to the AAS and the user isprompted for a user name and password (“what the user knows” and partone of multifactor authentication). The second part of the multifactorauthentication proceeds with reference to the FIG. 1E.

Initially, a phone number (or other device identifier) that is to beused by the AAS is preconfigured into the AAS by an administrator or, ifpolicy permits, by the user. Again, the AAS is configured to use asecure communication protocol, such as SSL and/or TLS (or others asdiscussed above).

At 1, the user selects a URL (or an address) associated with a protectedresource controlled or managed by the AAS. The resource is configured torequire multifactor authentication for access (the user name andpassword as one part, and as a second part what is described below withreference to this embodiment of the FIG. 1E).

At 2, the browser uses an HTML form to get the name and password fromthe user and sends the name and password to the AAS as a POST message.

At 3, the AAS validates the name and password (again, LDAP or othermechanisms). Next (assuming the name and password were validated), theAAS generates a challenge string. In an embodiment, the string israndomly generated by the AAS. Then, the challenge string and a user ID(acquired from validating the name and password) are encoded into anaudio format to form an audio file or audio message. Any availableapproach can be used to encode the information into an audio format toform the audio message.

At 4, the AAS returns an HTML page to the browser having an applicationor script that executes within the context of the browser on the desktopdevice (JAVA®, custom application, custom script, etc.).

At 5, the application or script executes on the desktop device to playthe audio message as an audio stream out of the speaker(s) interfaced tothe desktop device. The application or script also checks for success(see 9 below). The playing of the audio message can continue untilsuccess is detected unless a time out is detected (such as manual usertimeout, preconfigured number of iterations that the audio messageplays, or a preconfigured elapsed period of time during which the audiomessage was playing).

At 6, the AAS calls the phone number (or contacts the device) that it isconfigured to call (or to contact) for multifactor authentication. Theconfiguration can be based on the user ID, the protected resource thatthe user is attempting to authenticate to, and/or other policydirective(s).

At 7, the user answers the now ringing phone (or responds to the requestfor connection) based on the processing at 6 and places the answeredphone in proximity to a speaker of the desktop device. The phone's(device's) microphone receiver relays the sound emanating from thedesktop speaker and provides to the AAS during the call's connectionbetween the phone/device and the AAS.

At 8, the ASS decodes the audio received over the connection with thephone/device. The AAS validates that the audio sent back to the AAS, viathe connection to the phone, is the same audio message sent by the AASto the browser at 4.

At 9, the application or script of the browser checks to see if asuccess message or authenticated session handle (session identifier) isreceived from the AAS (indicating the user now has an authenticationsession to access the protected resource via the browser of the desktopdevice). If there is no such success, the application or script of thebrowser repeats the processing associated with 4-5 and 7-8. If anauthentication session handle is received, then processing continues to10.

At 10, the AAS returns an authentication session handle (sessionidentifier) to the browser for accessing the protected resource based onthe original POST message sent at 2. The user can now access theprotected resource.

It is noted that the description provided with respect to the FIGS.1C-1E described a single-vendor environment; although it is to be notedthat the approaches are equally as applicable to a multi-vendorenvironment by using a federation protocol, such as Security AssertionMarkup Language (SAML), WS-Fed (Identity Foundation Specification),OAuth (Open Standards for authorization), OpenID (OpenID Foundation),and/or other open standard protocols. In these cases, any web servicecan make a single SAML or other federation-based request to thetechniques of the invention and no knowledge of how the inventivetechniques of the invention would be needed. So, multifactorauthentication can be added to any web-based service that uses an openfederation protocol.

Moreover, other described aspects of the embodiments presented in theFIGS. 1C-1E can be changed as well, without departing from the teachingspresented herein.

For example, PKI does not have to be used; rather, any common key-basedalgorithm can be used. The devices need not be limited to a phone and adesktop device; in fact, any processor-enabled device can be used aseither the mobile device and/or the desktop device (tablet, laptop,wearable processing device, and the like). The browser can be anycustomized application processing on the device from which the protectedresource is initially requested. The PKI keys can be from a digitalcertificate with a specific root or parent. So, a company policy mayjust allow employees or partners to authenticate with the techniquespresented herein. Still further, in some embodiments, the mobileapplication can operate in a “push” mode, such that the AAS pushes amessage to the mobile device to start the mobile application on demand(so the mobile application need not, in each embodiment, be executinginitially on the mobile device to perform the audio multifactorauthentication techniques, since it can be initiated on the mobiledevice on demand when authentication is being processed—for exampleApple's push notification service for 105 devices can be used for Appledevices to initiate the mobile application). This same “push” approachcan also be used to set the keys or secrets on the mobile device thatthe mobile application uses to sign, and optionally encrypt, the audiomessage (so no pre-registration and acquisition of keys or secrets areneeded in each embodiment presented, instead a dynamic key or secretdelivery mechanism via the AAS can be deployed).

One now appreciates how multifactor authentication can be based on audioto provide a proximity-based guarantee that a user requestingauthentication is in proximity to a device from which access is beingrequested of a protected enterprise resource. The proximity is onlylimited by the tolerance of the devices to detect, via microphones,audio messages being played or relayed by other devices, via speakers.

These embodiments presented with the FIGS. 1A-1E and other embodimentsof the invention are now discussed with reference to the FIGS. 2-4.

FIG. 2 is a diagram of a method 200 proximity-based authentication,according to an example embodiment. The method 200 is implemented as oneor more software modules (herein after referred to as “serverauthentication agent”). The server authentication agent includesexecutable instructions that are implemented, programmed, and resideswithin memory and/or a non-transitory machine-readable storage media;the executable instructions execute on one or more processors of adevice and have access to one or more network connections associatedwith one or more networks. The networks may be wired, wireless, or acombination of wired and wireless.

In an embodiment, the server authentication agent resides on the AAS andrepresents the processing depicted and described above with reference tothe discussion of the FIGS. 1A-1E.

At 210, the server authentication agent sends an audio message to adevice. This is done in response to the device providing a first factorauthentication of a user that is requesting access to a protectedresource, which the server that executes the server authentication agentcontrols access to. In an embodiment, this device is the desktop devicedescribed above with reference to the FIGS. 1A-1E.

According to an embodiment, at 211, the server authentication agentrepresents the audio message as a randomly generated string and a useridentity associated with an authenticated user (achieved during thefirst factor authentication), who is requesting access to the protectedresource. The random generation of the string prevents reproduction ofthe string. Also, the message may include a cryptographic or digitalsignature to prevent modification of the random string or the useridentity. Moreover, the string is the challenge string discussed abovewith reference to the FIGS. 1C-1D.

So, in an embodiment at 212, the server authentication agent sends theaudio message after completing a first-factor authentication on arequest initiated by the user and received from the device for access tothe protected resource.

At 220, the server authentication agent receives a response message inresponse to the audio message that was sent to the device at 210. Thisresponse message can be received from the device (FIG. 1C) or from asecond device (FIGS. 1D-1E).

For example, at 221, the server authentication agent obtains theresponse message from a second device that captures the audio message asaudio being played over a speaker interfaced to the device (FIGS. 1C(mobile device) or 1D (landline phone)).

In an embodiment of 221 at 222, the server authentication agent verifiesa digital signature of the second device from the response message(FIGS. 1C-1D).

In another case of 221 at 223, the server authentication agent receivesthe response message as a duplicate version of the audio message from aphone connection established by automatically calling the second device.The audio message relayed during the phone connection as the audiomessage plays on the device (FIG. 1E).

It is noted that the response message in the embodiments of 221-222 doesnot have to be in an audio format (although in some cases it can be),since the second device is directly sending the response message forsecond factor authentication through the server authentication agent viaa secure network connection (such as SSL or TLS). In the embodiment of223, the response message is received in an audio format since it is arelayed version of the original audio message being played by thedevice.

In another case of 220 and at 224, the server authentication agentobtains the response message as a second audio message from the device.The second audio message is captured by the device when played on aspeaker of the second device (FIGS. 1C and 1D). It is noted that theserver authentication agent does not have to directly receive the audiomessage from the device but it originates from the device (FIG. 1Eduplicate version captured by the landline phone from the speakerinterfaced to the device and relayed during a phone connection to theserver executing the server authentication agent). The FIG. 1D depictsan embodiment where the device directly sends the response message tothe server authentication agent (in an audio format and received from amicrophone of the device as the response message plays on a speaker ofthe second device).

According to an embodiment, at 225, the server authentication agentcauses a mobile application to “wake up” and initiate on the seconddevice. This is done in response to a status check made by the deviceafter the first factor authentication was requested by the device (FIG.1D). The mobile application once initiated on the second device providesthe response message (FIGS. 1C-1D).

In an embodiment of 225 at 226, the server authentication agent pushes akey to the second device that the mobile application uses to sign theresponse message before providing the response message to the serverauthentication agent. So, the mobile device may not possess the means toachieve the second factor authentication on its own even with the mobileapplication; rather, a needed key is dynamically pushed to the mobiledevice each time authentication is being requested and the key can berandom, such that it is not reproducible for a second iteration ofauthentication with the server authentication agent.

At 230, the server authentication agent determines whether to provideaccess to the protected resource based on evaluation of the audiomessage and the response message. So, the server authentication agentknows the original audio message that it generated and uses that inconnection with the response message to make a determination as towhether the second factor authentication it to be deemed successful,such that access to the protected resource is to be granted. (Seedescription of the FIG. 1C (device provides the response message as amodified version of the original audio message provided as audio fromthe speaker of the second device), FIG. 1D (second device provides theresponse message based on decoding, signing, and optionally, encryptingthe original audio message, the response message communicated to theserver authentication agent via a secure connection from the seconddevice), and the FIG. 1E (the second device (landline phone) relays theresponse message as a duplicate version of the original audio message asthe device plays the original audio message over a speaker of thedevice.)

According to an embodiment, at 231, the server authentication agentprovides a session identifier or handle back to the device for access tothe protected resource when a determination is made (based on theevaluation at 230) to provide/grant access.

FIG. 3 is a diagram of another method for proximity-basedauthentication, according to an example embodiment. The method 300 isimplemented as one or more software module(s) (herein after referred toas “mobile device authentication agent”). The one or more softwaremodule are represented as executable instructions that are implemented,programmed, and resides within memory and/or a non-transitorymachine-readable storage medium; the executable instructions execute onone or more processors of a device and have access to one or morenetwork connections associated with one or more networks. The networksmay be wired, wireless, or a combination of wired and wireless.

In an embodiment, the mobile device authentication agent is the mobileapplication of the mobile device described above with reference to theFIGS. 1C-1D and 2.

At 310, the mobile device authentication agent detects an audio messageover a microphone interfaced to the mobile device that executes themobile device authentication agent (FIGS. 1C-1D).

In an embodiment, at 311, the mobile device authentication agentacquires the audio message as the audio message is played over a speakerin proximity to the microphone (FIGS. 1C-1D). The geographical distanceof the proximity is based on the tolerance level of the microphone andthe detected volume of the audio message played over the speaker.

At 320, the mobile device authentication agent generates a responsemessage in response to receipt of the audio message. In an embodiment,the response message is a modified version of the original capturedaudio message and the audio message includes a challenge string and auser ID for an authenticated user (authenticated during a first-factorauthentication); the challenge string and user ID included in theoriginal audio message produced by the server authentication agent ofthe FIG. 2 and also described in the FIGS. 1C-1D.

According to an embodiment, at 321, the mobile device authenticationagent prompts the user to input a PIN or other key into an interfaceassociated with the mobile device authentication agent on the mobiledevice. This can add a level of security to ensure an automated agent orunauthorized user is making a request for multifactor proximity-basedauthentication. A policy can be evaluated by the mobile deviceauthentication agent to determine if the key or PIN is required of theuser. Moreover, the policy can be dynamically changed via the serverauthentication agent of the FIG. 2 by pushing updates or new policies tothe mobile device authentication agent on the mobile device.

In another case, at 322, the mobile device authentication agent signsthe audio message as the response message that is generated. This wasdiscussed above with reference to the FIGS. 1C-1D.

In an embodiment of 322 and at 323, the mobile device authenticationagent encrypts the signed response message as well perhaps using adifferent key from what was used with the signature.

At 330, the mobile device authentication agent provides the responsemessage to the device. This is done for purposes of a second factorauthentication of the user requesting access to a protected resource.

In an embodiment, at 331, the mobile device authentication agent sendsthe response message in audio format for playing over a speakerinterfaced to the mobile device (the speaker in proximity to amicrophone interfaced to the device). This is done by providing theresponse message as audio to the device. Again, the device originallyplayed the audio message as audio over a speaker interfaced to thedevice and that speaker was in proximity to the microphone of the mobiledevice (FIG. 1C).

In another case, at 332, the mobile device authentication agent sendsthe response message to the device over a network connection. Here, thedevice is the server of the FIG. 2 that executes the serverauthentication agent. The device (server) provides the authentication toa second device (desktop device of the FIGS. 1A-1E) that originallyplayed the audio message as audio over a speaker, in proximity to themicrophone of the mobile device, which is interfaced to the seconddevice.

FIG. 4 is a diagram of a proximity-based authentication system 400,according to an embodiment. Various components of the proximity-basedauthentication system 400 are software module(s) represented asexecutable instructions, which are programed and/or reside within memoryand/or non-transitory computer-readable storage media for execution byone or more devices. The components and the devices have access to oneor more network connections over one or more networks, which are wired,wireless, or a combination of wired and wireless.

According to an embodiment, the proximity-based authentication system400 implements, in whole or in part and inter alia, various features ofthe FIGS. 1A-1E and 2-3.

The proximity-based authentication system 400 includes a server 401 anda server authentication module 402.

The server 401 includes one or more processors, memory, and non-volatilestorage. In an embodiment, the server 401 is the AAS depicted anddiscussed above with reference to the FIGS. 1A-1E. The server 401 iscapable of establishing multiple connections to multiple networks, suchas cellular networks, Wi-Fi networks, Ethernet networks, and the like.

The server 401 includes a server authentication module 402. The serverauthentication module 402 is implemented as one or more software moduleshaving executable instructions that execute on the one or moreprocessors of the server 401. In an embodiment, the serverauthentication module 402 when executed performs the processing depictedin the FIGS. 1A-1E and 2.

The server authentication module 402 is adapted (configured) to: i)generate an audio message; ii) provide a script (or application) forexecution on a device (the device configured to play an audio messageover a speaker interfaced to the device); iii) validate a responsemessage received from at least one of: the device (depicted in the FIG.1C) and a second device (depicted in the FIG. 1D); and iv) provide adetermination as to whether a user interacting with the device is to begiven access to a resource requested by the user (FIGS. 1C-1E).

According to an embodiment, the device is a desktop device and thesecond device is one of: a cellular phone (FIG. 1C-1D) and a landlinephone (FIG. 1E).

In an embodiment, the response message is at least one of: encrypted andsigned by the second device (FIGS. 1C and 2) and a duplicated version ofthe audio message captured by the server authentication module 402during a phone connection with the second device as the device plays theaudio message over the speaker (FIGS. 1E and 2).

One now fully appreciates how multiple devices and audio can be used toachieve multifactor authentication against a user requesting access to aprotected resource. Such novel and proximity-based multifactorauthentication has application in a variety of areas, such as, but notlimited to, access to financial assets, financial transactionprocessing, access to confidential operations or information, and thelike.

The above description is illustrative, and not restrictive. Many otherembodiments will be apparent to those of skill in the art upon reviewingthe above description. The scope of embodiments should therefore bedetermined with reference to the appended claims, along with the fullscope of equivalents to which such claims are entitled.

1. (canceled)
 2. A method, comprising: capturing, by a microphone of afirst device, an audio message being played over speakers of a seconddevice; generating, by the first device, a response message for thecaptured audio message; and providing, by the first device, the responsemessage to the second device as an authentication message for accessinga resource controlled by the first device.
 3. The method of claim 2,wherein capturing further includes capturing by the microphone the audiomessage as the second devices plays the audio message over the speakers.4. The method of claim 2, wherein generating further includes promptinga user that is operating the first device to input a personalidentification number and using the personal identification number whengenerating the response message.
 5. The method of claim 2, whereingenerating further includes generating the response message by signingthe audio message with a key.
 6. The method of claim 5, whereingenerating further includes encrypting the signed audio message forproducing the response message.
 7. The method of claim 2, whereinproviding further includes sending the response message from the firstdevice to the second device over a network connection between the firstdevice and the second device.
 8. The method of claim 2, whereinproviding further includes communicating the response message to thesecond device by the first device playing the response message as audioover first device speakers for being captured by a second devicemicrophone.
 9. The method of claim 2, wherein capturing further includesidentifying a user identifier for a user operating the first device anda challenge string.
 10. The method of claim 9, wherein generatingfurther includes prompting the user to provide a response to thechallenge string when generating the response message.
 11. The method ofclaim 2, wherein capturing further includes identifying from the audiomessage that a user has already performed a first factor authenticationfor accessing the resource and the response message is processed by thesecond device as a second factor authentication for the user to gainaccess to the resource.
 12. The method of claim 2, wherein providingfurther includes sending the response message to a server and the serverproviding a modified response message to the second device indicatingthat the first device is authenticated for accessing the resource of thesecond device.
 13. A method, comprising: registering a mobile deviceoperated by a user with a server for multifactor audio authenticationfor the user to access a resource controlled by a second device;performing, by the server, a first factor authentication on the userwhen the user accesses a link to the resource while operating the seconddevice; generating, by the server, a string and appending a useridentifier acquired from the user during the first factor authenticationto create an audio message and providing the audio message to the seconddevice; playing, by the second device, the audio message over a speakerof the second device; capturing by a microphone of the mobile device theaudio message; signing, by the mobile device, the audio message;playing, by the mobile device, the signed audio message over mobiledevice speakers; capturing, by a second device microphone, the signedaudio message; providing, by the second device, the signed audio messageto the server; performing, by the server, a second factor authenticationusing a public key provided for the mobile device during registrationfor verifying the signed audio message; and permitting, by the seconddevice, access to the resource when the signed audio message is verifiedsuccessfully by the server based on a validation message provided fromthe server to the second device.
 14. The method of claim 13, whereinperforming the first factor authentication further includes redirectingthe link to the server;
 15. The method of claim 14, wherein redirectingfurther includes obtaining the user identifier and a password that aresupplied by the user in response to the server presenting a login screenrendered to the second device for entry by the user.
 16. The method ofclaim 15, wherein obtaining the user identifier further includesauthenticating the user identifier and the password against an accountregistered with the server for the user.
 17. The method of claim 16,wherein generating further includes randomly generating the stringensuring the string is unique to the user attempting to access theresource on the second device.
 18. The method of claim 13, whereinproviding the signed audio string further includes providing, by thesecond device, the signed audio string in a demodulated format.
 19. Themethod of claim 13, wherein providing the signed audio string furtherincludes providing, by the second device, the signed audio string in anaudio format.
 20. A system, comprising: a server; a mobile device; and asecond device; wherein a user operates the mobile device and the seconddevice, and wherein the second device is configured to control access toa protected resource, wherein when the user attempts to access theprotected resources from the second device, the user is redirected to alogin screen of the server for the server to perform a first factorauthentication, and the server further configured to generate an audiomessage that is provided to the second device when the user successfullyauthenticates for the first factor authentication, and wherein thesecond device is configured to play the audio message over speakers, andthe mobile device configured to: capture the audio message from amicrophone, sign the audio message with a key to produce a responseaudio message, and play the response audio message over a mobile devicespeaker, the second device configured to: capture the response audiomessage from a second device microphone, and send the response audiomessage to the server, the server is configured to: perform a secondfactor authentication by verifying a signature provided by the mobiledevice that is present in the response audio message and provide anauthentication response back to the second device, and the second deviceis further configured to provide the user access from the second deviceto the protected resource when the authentication response indicates theuser was authenticated during the second factor authentication by theserver.
 21. The system of claim 20, wherein the mobile device is one of:a smart phone, a tablet, a laptop, and a wearable processing device, andwherein the server is part of a cloud processing environment, and thesecond device is one of: a desktop, a laptop, and a tablet.